Application program interfaces (hereafter API), constituted by instructions, functions and protocols for developing an application program (hereafter application) which runs on such a platform of an operating system (hereafter OS) and middleware have been provided. A user who develops an application calls up an API, which corresponds to a desired function, on a program, so as to install this function in an application.
An application developed for a specific platform cannot run on a different platform. However one of the following two methods makes it possible for an application developed for one platform to run on a different platform. The first method is rewriting an API called up by the application to be an API of a different OS of the porting destination. The second method is creating a wrapper program, which converts an API of the porting source OS into an API of the porting destination OS, and calling up the API of the porting destination OS via the wrapper program.
In the case of the first method, the API of the porting destination OS is called up directly by the application, hence overhead is low and memory capacity to be used can be minimized. The downside, however, is that the application which has been operating on the porting source OS is modified, therefore the application may have problems, and the application must be verified again.
In the case of the second method, the application need not be modified since a wrapper function, to convert the API of the porting source OS into the API of the porting destination OS, is provided. On the other hand, overhead during application execution increases, and memory capacity to be consumed becomes higher than the first method. However the application which has been operating at high reliability is not modified, hence it is easy to specify a problem area when trouble occurs. Furthermore, a wrapper program can be provided for each API, therefore man-hours can be decreased, and porting becomes more efficient compared with the first method which requires rewriting all the APIs in the application. As a consequence, the second method is more frequently used (e.g. Japanese Patent Application Laid-Open No. 2004-246690 and Personal Media Co. Ltd., “i-right/TK”, searched on Jan. 31, 2011: internet url: http://www.t-engine4u.com/products/iright_tk.html).
However there are differences between a porting source OS and a porting destination OS, not only in arguments and return values of the interface in each API, but also in the error values and status values (e.g. OS mode, task status information, memory size) of each OS. This means that if the API of the porting source OS is merely converted into the API of the porting destination OS within the wrapper program, the error values and status information to be output from the API in the porting destination OS to the application may not be the same as those of the porting source OS. If the error values and status values to be output to the application are different between the porting source OS and the porting destination OS unexpected values are output from the wrapper program to the application, and the application malfunctions.
To solve this problem, it is necessary for a programmer, who is very knowledgeable about the specifications of both the porting source OS and the porting destination OS, to generate a wrapper program, and in this wrapper program, the output values of the error values and status values to the application must conform to the protocol of the porting destination OS. But if the wrapper program is programmed to convert the output values of the error values and status information so as to conform to the protocol of the porting source OS, then not only calling up the API of the porting destination OS, but also converting the output values, to indicate the processing result of the called up API (e.g. error values and status values), is required for the wrapper program, hence overhead increases and efficiency drops.